Access Control Measures are not implemented for all conferences hosted on a centralized MCU appliance.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-17719	RTS-VTC 5020.00	SV-18893r1_rule	ECPA-1 IAIA-1 IAIA-2	Medium

Description
Access control must be exercised over participants joining multipoint conferences. Attendees and/or endpoints must be pre-authorized or pre-registered. In this way, conference/meeting organizers can control who has access to sensitive or classified information based upon validated clearance and need-to-know. Unrestricted access or the use of a meeting password that is reused and/or well known can lead to a security incident where information is improperly disclosed to unauthorized individuals not having appropriate clearance or need-to-know. In a previous topic, we discussed the access control required for multipoint conferences hosted by a VTC endpoint with an integrated MCU. Typically access control for such meetings is handled manually by the operator of the hosting VTU calling the participants and joining them to the conference. This is positive access control with the conference host controlling who has access to the session and being responsible, therefore, for the conferees need-to-know or authorization to receive conference information. Additionally, if call-in access is supported and approved, a one time use meeting password is required. Multipoint conferences hosted on a MCU appliance or network element must also perform access control over who can join a meeting. This includes employing proper practices for distributing conference information as well as for assigning access codes. If access control is not exercised, anyone who knows any phone number or IP address on the MCU can “dial-in” any time and access whatever meeting is being hosted on the MCU at the given time. This cannot be permitted. MCU Access control can be performed in various ways that may differ from vendor’s product to vendor’s product. Typically, MCU access is controlled by an H.323 gatekeeper, which uses H.225 gatekeeper RAS messages between itself and its endpoints. A combination of access control lists on the MCU and gatekeeper can also limit access. A full description of this process is beyond the scope of this release of this STIG but a brief description follows along with an issue. Further information can be found in several books and tutorials that are available in both print and on the web. H.323 gatekeepers provide access control for VTC network infrastructure devices such as MCUs and gateways to VTC endpoints. Using H.225 an endpoint can discover a gatekeeper and register with it. The endpoint is identified by the gatekeeper by a “gatekeeper password” which is essentially the endpoint ID. The gatekeeper provides address translation and bandwidth management. Once registered with the gatekeeper an endpoint must ask permission of the gatekeeper to make a call. If the available VTC bandwidth is used or limited, the gatekeeper can reject the request or negotiate a lower bandwidth. This acts as part of the access control mechanism for the MCU and works in combination with a scheduling application. The rest of the MCU access control equation is pre registration of the endpoint IDs when scheduling a conference. Pre registration of endpoint IDs for specific conferences is required because there are typically no meeting passwords and the phone numbers or IP addresses of the MCU ports don’t change between sessions. Additionally (and here’s the issue mentioned above) people are not authenticated only endpoints are. The endpoint ID is critical in this access control process. The endpoint ID is entered (pre-configured) in the system for a specific scheduled conference. The system only permits the endpoint to access the MCU during the scheduled time of the conference. This discussion also applies to ad hoc conferences and “standing” conferences. A standing conference is one where MCU facilities are dedicated to a conference that is operational all of the time or one that is regularly scheduled to be operational for certain time periods. The implementation of a standing conference permits conferees to join the conference at will or as needed to discuss a current topic or mission. Standing conferences are implemented for many reasons. Standing conferences are more vulnerable to compromise than one time scheduled events. Extra care must be exercised regarding access control to these conferences. Note: This general requirement is supported by several DoDI 8500.2 IA controls such as IAIA-1, IAIA-2, and ECPA-1.

Description

Access control must be exercised over participants joining multipoint conferences. Attendees and/or endpoints must be pre-authorized or pre-registered. In this way, conference/meeting organizers can control who has access to sensitive or classified information based upon validated clearance and need-to-know. Unrestricted access or the use of a meeting password that is reused and/or well known can lead to a security incident where information is improperly disclosed to unauthorized individuals not having appropriate clearance or need-to-know. In a previous topic, we discussed the access control required for multipoint conferences hosted by a VTC endpoint with an integrated MCU. Typically access control for such meetings is handled manually by the operator of the hosting VTU calling the participants and joining them to the conference. This is positive access control with the conference host controlling who has access to the session and being responsible, therefore, for the conferees need-to-know or authorization to receive conference information. Additionally, if call-in access is supported and approved, a one time use meeting password is required. Multipoint conferences hosted on a MCU appliance or network element must also perform access control over who can join a meeting. This includes employing proper practices for distributing conference information as well as for assigning access codes. If access control is not exercised, anyone who knows any phone number or IP address on the MCU can “dial-in” any time and access whatever meeting is being hosted on the MCU at the given time. This cannot be permitted. MCU Access control can be performed in various ways that may differ from vendor’s product to vendor’s product. Typically, MCU access is controlled by an H.323 gatekeeper, which uses H.225 gatekeeper RAS messages between itself and its endpoints. A combination of access control lists on the MCU and gatekeeper can also limit access. A full description of this process is beyond the scope of this release of this STIG but a brief description follows along with an issue. Further information can be found in several books and tutorials that are available in both print and on the web. H.323 gatekeepers provide access control for VTC network infrastructure devices such as MCUs and gateways to VTC endpoints. Using H.225 an endpoint can discover a gatekeeper and register with it. The endpoint is identified by the gatekeeper by a “gatekeeper password” which is essentially the endpoint ID. The gatekeeper provides address translation and bandwidth management. Once registered with the gatekeeper an endpoint must ask permission of the gatekeeper to make a call. If the available VTC bandwidth is used or limited, the gatekeeper can reject the request or negotiate a lower bandwidth. This acts as part of the access control mechanism for the MCU and works in combination with a scheduling application. The rest of the MCU access control equation is pre registration of the endpoint IDs when scheduling a conference. Pre registration of endpoint IDs for specific conferences is required because there are typically no meeting passwords and the phone numbers or IP addresses of the MCU ports don’t change between sessions. Additionally (and here’s the issue mentioned above) people are not authenticated only endpoints are. The endpoint ID is critical in this access control process. The endpoint ID is entered (pre-configured) in the system for a specific scheduled conference. The system only permits the endpoint to access the MCU during the scheduled time of the conference. This discussion also applies to ad hoc conferences and “standing” conferences. A standing conference is one where MCU facilities are dedicated to a conference that is operational all of the time or one that is regularly scheduled to be operational for certain time periods. The implementation of a standing conference permits conferees to join the conference at will or as needed to discuss a current topic or mission. Standing conferences are implemented for many reasons. Standing conferences are more vulnerable to compromise than one time scheduled events. Extra care must be exercised regarding access control to these conferences. Note: This general requirement is supported by several DoDI 8500.2 IA controls such as IAIA-1, IAIA-2, and ECPA-1.

STIG	Date
Video Services Policy STIG	2015-02-05

Details

Check Text ( C-18989r1_chk )
[IP][ISDN]; Interview the IAO and validate compliance with the following requirement: Ensure access control measures are implemented for all conferences hosted on a centralized MCU appliance (i.e., not part of an endpoint) as follows: - Only authorized endpoints are permitted to access an MCU AND/OR - Only authorized users are permitted to access/join a conference. Authorization is pre-configured on the MCU access control system and is based on validated need-to-know as well as security clearance if applicable. Note: this applies to standing, scheduled one-time, and non-scheduled ad hoc conferences. . Interview IAO and verify with SA and users that only authorized endpoints are permitted to connect to a centralized MCU for conferences. Inspect MCU to verify that there is a mechanism in place that authorization is required prior to accessing/joining conference.

Check Text ( C-18989r1_chk )

[IP][ISDN]; Interview the IAO and validate compliance with the following requirement:

Ensure access control measures are implemented for all conferences hosted on a centralized MCU appliance (i.e., not part of an endpoint) as follows:
- Only authorized endpoints are permitted to access an MCU
AND/OR
- Only authorized users are permitted to access/join a conference. Authorization is pre-configured on the MCU access control system and is based on validated need-to-know as well as security clearance if applicable.

Note: this applies to standing, scheduled one-time, and non-scheduled ad hoc conferences.
.
Interview IAO and verify with SA and users that only authorized endpoints are permitted to connect to a centralized MCU for conferences. Inspect MCU to verify that there is a mechanism in place that authorization is required prior to accessing/joining conference.

Fix Text (F-17616r1_fix)
[IP][ISDN]; Perform the following tasks: Ensure access control measures are implemented for all conferences hosted on a centralized MCU appliance (i.e., not part of an endpoint) as follows: - Only authorized endpoints are permitted to access an MCU AND/OR - Only authorized users are permitted to access/join a conference. Authorization is pre-configured on the MCU access control system and is based on validated need-to-know as well as security clearance if applicable. Note: this applies to standing, scheduled one-time, and non-scheduled ad hoc conferences.

Fix Text (F-17616r1_fix)

[IP][ISDN]; Perform the following tasks:
Ensure access control measures are implemented for all conferences hosted on a centralized MCU appliance (i.e., not part of an endpoint) as follows:
- Only authorized endpoints are permitted to access an MCU
AND/OR
- Only authorized users are permitted to access/join a conference. Authorization is pre-configured on the MCU access control system and is based on validated need-to-know as well as security clearance if applicable.

Note: this applies to standing, scheduled one-time, and non-scheduled ad hoc conferences.